实战 | 总有刁民想害朕——Payments打造360°监控体系的实践
导读
还在为众多的BUG而愁眉苦脸,惴惴不安?
还在为应用的稳定性苦思忧虑,寝食难安?来!概述
近来我司SRE团队发了一个叫做《SRE重案调查组》的系列文章,里面记录了他们非常牛逼怪诞诡谲的DEBUG过程,读上去颇有一种风起云涌惊心动魄的感觉。
只不过,这一系列的文章,聚焦在特定问题上。除此之外,还有一个关键问题——即对于一个应用,尤其是业务系统来说,如何构建一个经得起考验的监控体系呢?
一个应用,从上线开始,开发者就要陷入一种焦虑:担心系统会不会崩掉,有没有什么情况没被考虑到,用户体验好不好…...
这种焦虑就像是老母亲好不容怀胎十月生下一个孩子,心里还没有松口气,又陷入另外一种忧虑,担心他吃不吃得好,睡不睡得着,会不会生病……
即便系统稳定运行一段时间之后,依旧无法遏制地觉得它会出问题。再想到半夜接到on-call电话爬起来修BUG,这种心情,大抵是,总有刁民想害朕。
俗话说,兵马未动,狗腿先行。这第一步,当然是把朕的“六扇门”CAL放出来了……
六扇门CAL
普天之下莫非王土
CAL是什么呢?CAL是一个基于结构化日志的分布式监控系统,其全称是“Central Application Log”。点评美团CAT大家多少有所耳闻,但是很多人并不知道, CAL实际上是CAT的先驱和基石。
CAL是历史最悠久,也是最基础的监控手段,一个项目启动之际,就要考虑接入CAL。因此我喜欢把它比作“六扇门”——江湖人对衙门捕快的俗称。CAL提供了一家公司所需要的最基本的监控手段:
图1(点击可查看大图)
这种主要用于排查问题,即DEBUG。
图2(点击可查看大图)
利用它的错误统计,我们曾经发现一个很有意思的问题。在某一次的发布中,流量逐步放开,最开始每次放开1%的流量。
在观察Error数量的时候,我们就发现有点不太对劲。按道理来说,错误数量和流量是同比例增长的关系,即如果流量增加N倍,那么错误数量也应该增加N倍。例如在10%流量的情况下,平均每分钟的错误数量是100个,那么在100%流量的情况下,平均每分钟的错误数就应该是在1000个左右,波动不会特别大。
很显然,此次发布必然存在有问题。而后我们找到对应Error的CAL,发现下游返回的一个响应有问题。该响应在系统中被多次用到,每一次使用,都会出现一个Error。这样就造成了Error“暴涨”的现象——这种错误和分布式环境下的“异常雪崩”倒是有几分相似。
图3(点击可查看大图)
俗话说,没有告警的监控系统是没有灵魂的,所以我们还有一个基于CAL的告警系统。该系统允许用户配置各种规则,当系统匹配触发到某条规则的时候,用户就能收到各种告警信息了。
图4(点击可查看大图)
在应用上线之后,都要设置好这些告警规则。常见的告警在机器层面上有:JVM full GC, GC pause time,CPU负载;在业务层面,则是依据具体的业务场景来设置,一般而言都会设置错误数量相关的告警。
CAL的告警尚且不够智能。因为这种规则设置是比较死板的,所以当收到告警的时候,并不一定就是真的出问题了。具体还要结合业务信息,或者其他监控工具的观测结果,才能断定是否真的出现了问题。
而且记录太详细也是要付出代价的。CAL的数据保存期限比较短,查询也较慢。很多情况下,当我们心急火燎地去找某个CAL记录的时候,总是“等到花儿都谢了”才找着,甚至晚一点就根本找不到了。
毋庸讳言,CAL不负其“国之柱石”的地位,每个应用接入之后,最起码的监控信息就都有了。但老话说“闻道有先后,术业有专攻”,CAL也并非全能型选手。由于其较为基础且全面,所以在一些特定的场景之下,就会显得比较无力,需要别的工具作为补充。
司礼监DW
天下文书皆汇于此
所以,我们需要一个全局的机构,汇总数据,进行分析和筛选。为此我们接入了数据仓库——被我比喻为司礼监,毕竟司礼监“掌天下机要”。当然也是因为要硬凑一个比喻。
DW这个东西,主要依赖于定时来产生一些报表,通过这些报表来分析一些蛛丝马迹。和CAL比起来,DW的目的性更强并且分析也更细致。
比如说,我们接入DW之后就迅速利用DW来记录S系统的错误码,以及一些错误信息。
早期我们发现,单纯看CAL的总体数量统计是不够的。有些时候,错误数量总体平稳,你去看一时半会也发现不了问题。但是如果对这些错误进行分类分析,就会发现问题。
举个“栗子”,假如我们的系统只有两种错误:A和B,那么总体数量就是A+B,这个和可以很稳定,但是某次发布之后,A下降了而B上升了,但是总和大体不变。如果不分类分析的话,是无法发现这种变化的。
图5(点击可查看大图)
要使用DW,唯二要做的事情就是自己设计DW里面的数据表和编写数据分析脚本。
锦衣卫Pulsar
水银泻地无孔不入
按道理来说,前面两步搞完之后,似乎就可以“二世三世至于万世,传之无穷”了。然而前面这两位,都还有一个先天不足,就是它们更倾向于“事后诸葛”,即只有当我出了什么问题,它才能派上用场。
图6(点击可查看大图)
东厂ELK
缇骑四出缉拿天下
可是,经过一番思考之后,朕总觉得前面那几位还是不够让人放心。
比如某天,我们想要搞个比较复杂的搜索,像是某个时间段内因某两个原因退款失败的订单号,又或者是根据某些关键字来搜索日志,那么前面的所有工具都要懵逼了。
因此,我们需要一个更加狗腿的机构,这个机构就是以朕的喜好为目的,让偷狗就绝不辇鸡。这就只能是ELK了!ELK全称是“Elasticsearch-Logstash-Kibana”,俗称“日志三宝”。一个目的性更强,实时性更好,搜索更强大的监控工具。
图7(点击可查看大图)
图8(点击可查看大图)
接入了ELK之后,有一个柱形图引起了我们的兴趣:
图9(点击可查看大图)
为什么说有趣呢?因为我们看到之所以退款失败,很大程度上是因为CONFLICT_CASE_EXIST。
图9中的错误信息表示的是,如果这个订单已经有一个“售后流程”(如退款、订单取消、退货等)在处理中,那么就不允许再一次发起退款。比如说该订单已经发起了一个退款,那么再次尝试发起退款就会失败。
这实际上是一种过于严苛的业务逻辑了。因为在前面举例的两种情况下,禁止是毫无道理的,反而应该放开这种限制,这样能带来更好的用户体验。如今,这种改进已经提上议程,就等发布上线了。
ELK并不是无侵入式的。我们需要根据自身的监控目标来设计ES索引,而后在业务代码里面嵌入日志采集代码。
总结
现在我们需要全方面讨论一下这些工具了。毕竟有对比才有伤害。
一般会从四个角度来衡量一个监控的功效(如图10所示):
系统故障:如机器自身的状态,网络的状态; 业务指标:如业务出错量,订单量,成交金额等; 应用性能:如各个服务的响应时间; 用户行为:如用户的输入输出特征,页面驻留特征。
图10(点击可查看大图)
而判断一个工具好不好用则是从四个角度来衡量(如图11所示):
数据详细程度,是否含有统计数据; 时效性; 数据保存期限; 查询速度。
图11(点击可查看大图)
如果用排兵布阵来形容我们Payments的监控体系,那么应该:
1)以CAL为中军——最为基础的监控;
2)DW和Pulsar为两翼——能够提供各有特色的监控内容;
3)ELK为前锋——逢山开路遇水搭桥,也是最为精锐的部分。
作者介绍
邓明 (Ming):Payments产品开发工程师
一位上能撸码,下能撰文的小萌新
张杨 (Frank):Payments产品开发工程师
能搞定从遗留系统改造到使用最新技术栈产品开发的“攻城狮”一枚 ,在payments内部的技术问题,stack overflow解决不了的,可以问Frank :-)
您可能还感兴趣:
干货 | eBay Kubernetes集群的存储实践实战 | eBay PB级日志系统的存储方案实践SRE重案调查组 第一集 | 高延迟问题的罪魁祸首System.gc()SRE重案调查组 第二集 | 挖掘应用处理变慢的“真相”SRE重案调查组 第三集 | 探秘HTTP异步请求的“潘多拉魔盒”SRE重案调查组 第四集 | JVM元数据区的内存泄漏之谜SRE重案调查组 第五集 | 为什么我的服务器又双叒不响应了?!
SRE重案调查组 第六集 | 剖析Java的非常规线程死锁问题你还可以:
↓点击阅读原文,直接开启网申之旅~